The problem of supporting roaming between wireless subnets is known. A client utilizing an Internet Protocol (“IP”) session suffers an interruption when roaming between subnets while protocols are executed to establish a new IP address for the client. This happens because the IP address assigned to the client in the subnet that is being exited is not initially associated with the client in the subnet being entered. Session interruptions are problematic because some applications are sensitive to interruptions. For example, some applications may timeout or fail as a result of the interruption. In any event, noticeable delays may be annoying to the person using the client device even if the application does not timeout or fail.
It is known to facilitate roaming by maintaining the client IP address across subnet boundaries. This is done by establishing a tunnel from the subnet being entered to the subnet being exited. In particular, a switch in the subnet being entered creates the tunnel to a switch in the subnet being exited. Because the IP address employed by an application or service to communicate with the client is unchanged, there is no interruption. The technique facilitates roaming because it is transparent to both the service and the client. However, the switch in the subnet being entered is required to examine packets to identify roaming clients. In particular, the switch processes all received packets to determine whether the subnet address specified in the packets is associated with the subnet directly supported by that switch. If some other subnet is indicated, then a roaming client has been detected and the tunnel is created. However, examining packets to this extent is computationally costly, and somewhat wasteful because most packets examined are unlikely to be associated with a roaming client.